Block storage (input/output) devices are typically used as mass storage devices. For example, the most common block device is a hard disk drive. Other common block devices include optical storage devices, removable storage media devices (e.g., Iomega's zip drives, USB-based detachable solid state memory), CD-ROM devices, and floppy drives.
A typical block storage device access interface stack in accordance with conventional practices is shown in FIG. 1. The stack is divided into two major portions: software components 100 and hardware components 102. Software components 100 include an operating system (OS) having a kernel 106 and user space 108. A user application 110 runs in the user space 108, while an OS device driver 112 resides at the kernel level of the OS.
The hardware components 102 include a firmware device driver 114, a device controller 116, and a block storage device 118, such as a hard disk drive 120. The firmware device driver 114 and device controller 116 typically reside on a computer system motherboard 122. More specifically, the firmware device driver typically resides on a boot firmware device (e.g., “BIOS chip”) on motherboard 120, while the device controller may comprise a separate component mounted on motherboard 122, or may be includes as part of the system's chip set.
The interface stack in FIG. 1 is used to abstract the underlying block storage from users running application in user space 108. For example, suppose user application 110 comprises a file access application such as Microsoft's Explorer, which depicts the file structure stored on mass storage devices like disk drive 120 as a file tree 124. The underlying file data are addressed as blocks on block storage device 118, hence the name “block device.” However, the concept of addressable blocks of storage cannot directly support a workable user interface, such as file tree 124. Thus, components in the OS kernel, including OS device driver 112, are used to abstract the user interface from the underlying storage. These components include a FAT (file allocation table) 126, which maps files and folders to corresponding storage blocks via a block address map 128. A partition table 130 is also included. In addition to dividing the block address of block storage device 118 into necessary partition, partition table 130 may also be used to create logical partitions, such that the same physical block storage device may appear to applications running in operating system 104 as separate “virtual” storage devices.
Generally, the components at the OS kernel 106 layer control access to a systems block storage devices, using software abstractions. However, under most implementations, anyone running the computer system has access to data stored on a system's own block storage devices, while remote block storage devices hosted by other remote systems may be access if sharing is enabled for such devices (via the OS's on the remote systems), and if the user has proper credentials to use the share(s).
In addition to block address mapping, the OS kernel is responsible for file/directory access. That is, a component such as FAT 16 maintains file access attribute data that define the types of accesses that are allowed. For example, a file may have a “read-only” attribute that prevents the file from being modified. Other files may be “hidden,” or otherwise only accessible to someone with the proper authority, such as a system administrator. Thus, the operating system is the gatekeeper for accessing block storage devices under conventional practices.